Radiocommunication networks were originally developed primarily to provide voice services over circuit-switched networks. The introduction of packet-switched bearers in, for example, the so-called 2.5 generation (G) and 3G networks enabled network operators to provide data services as well as voice services. Eventually, network architectures will likely evolve toward all Internet Protocol (IP) networks which provide both voice and data services. However, network operators have a substantial investment in existing infrastructures and would, therefore, typically prefer to migrate gradually to all IP network architectures in order to allow them to extract sufficient value from their investment in existing infrastructures. Also to provide the capabilities needed to support next generation radiocommunication applications, while at the same time using legacy infrastructure, network operators could deploy hybrid networks wherein a next generation radiocommunication system is overlaid onto an existing circuit-switched or packet-switched network as a first step in the transition to an all IP-based network. Alternatively, a radiocommunication system can evolve from one generation to the next while still providing backward compatibility for legacy equipment.
Specification is ongoing in 3GPP for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) that is the next generation of Radio Access Network (RAN). Another name for E-UTRAN, used in the present specification, is Long Term Evolution (LTE) RAN. The core network to which E-UTRAN is connected is called Evolved Packet Core (EPC), also known as System Architecture Evolution (SAE) network. Both the E-UTRAN and the EPC (and possibly some other node(s), such as the Home Subscriber Server (HSS), depending on the definition of the EPC) comprise together the Evolved Packet System (EPS), which is also known as the SAE/LTE network. A base station in this concept is called an E-UTRAN NodeB (eNodeB or eNB). These ongoing studies also include the possibility to have an E-UTRAN base station which provides home or small area coverage for a limited number of users. This base station is, in 3GPP and in this document, called a Home E-UTRAN NodeB (HeNB) or home base station. Other names used for this type of base station are LTE Home Access Point (LTE HAP) and LTE Femto Access Point (LTE FAP). In 3G Universal Mobile Telecommunication System (UMTS) the equivalent base station to an HeNB is referred to as a Home Node B (HNB). While HeNBs are used herein, similar concepts apply to the HNB of the 3G UMTS systems.
An HeNB typically provides regular service for the end users and can be connected to the mobile core network using an IP-based transmission link. The radio service coverage provided by an HeNB is called a femtocell in this application. Furthermore, a femtocell is normally a Closed Subscriber Group (CSG) cell, i.e., a cell in which only a limited but variable set of users is normally allowed to access the network. The HeNB would, in most cases, use the end user's already existing broadband connection (e.g. xDSL and Cable) to achieve connectivity to the operator's Public Land Mobile Network (PLMN) and possibly to other eNBs/HeNBs. One of the main reasons for providing wireless local access using HeNBs and femtocells is to provide cheaper calls or transaction rates/charges when a device (e.g., a mobile phone) is connected via an HeNB as compared to when that device is connected via an eNB.
More generally, an HeNB and similar devices can be considered to be a sort of “home base station”. As used herein, the term “home” is used to modify the phrase “base station” to distinguish such equipment from other conventional base stations based upon characteristics such as one or more of: (1) geographic radio coverage provided (i.e., home base station coverage area is normally less than “regular” base station coverage area), (2) subscriber access (i.e., the subscribers who can obtain service from the home base station may be limited whereas a “regular” base station will typically provide access to any subscribers (or at least to a larger group of subscribers than a home base station) who are within range), and (3) home base stations are normally installed by the end users themselves without any intervention from the operator's personnel, whereas regular base stations are typically installed by operator personnel. This latter quality of home base stations suggests that the installation will generally be highly automated and of a “plug and play” nature. Note, however, that home base stations need not literally be installed in personal residences, and may find applications in businesses, public areas, etc., wherein the qualities of a home base station are desirable to, e.g., supplement coverage provided by regular base stations. Home gateways, as the phrase is used herein, are gateways which interface home base stations with a node in the radiocommunication system, e.g., a core network node.
When a subscriber from one PLMN visits another PLMN this is referred to as “roaming”. Therefore, in the context of this document, when a subscriber is included in the CSG of another PLMN/operator than the subscriber's home operator, this is referred to as “CSG roaming” and the concerned subscriber is referred to as a “foreign subscriber”.
The problem that arises in conjunction with CSG roaming is related to the management of CSG data and CSG Whitelists, which are designed with a single PLMN in mind (to which both the HeNB and the CSG members are assumed to belong). The CSG data is managed by the Operation Maintenance Administration and Provisioning (OMA&P) system (sometimes also known as OAM&P system) of the PLMN to which the HeNB connects. The OMA&P system deals with, for example, configuration, supervision and tuning of the radiocommunication network, administration of subscriber related data and provisioning of data, features and services. The CSG Whitelist of a subscriber, which includes identities of the CSGs the subscriber is a member of and thus is allowed to access, is managed by the OMA&P system and the HSS of the subscriber's home PLMN and the subscriber's UE (e.g., its USIM). Finally, the CSG based access control is handled by a control plane core network node, e.g., an MME or SGSN (or possibly MSC or MSC server)) which the HeNB is connected to, i.e., a core network node of the PLMN of the HeNB and associated CSG. Hence, if the HeNB and a subscriber included in the CSG belong to different PLMNs, cooperation between the involved entities of the two different PLMNs is required to manage the CSG data and the CSG Whitelist, as well as the CSG based access control. This cooperation and information transfer that is needed is not possible to achieve with the currently assumed architecture and functionality, due to lack of the required inter-PLMN interfaces and procedures. Specifically, the OMA&P systems of two different PLMNs cannot communicate this type of CSG information directly to update each other.
For example, data generally cannot be exchanged between the OMA&P system of one PLMN and the HSS of another PLMN and the OMA&P system of one PLMN cannot transfer data (e.g., using Open Mobile Alliance (OMA) device management (DM) or over-the-air (OTA) technology) to the UE of a subscriber of another PLMN. OMA DM is a protocol designed for configuration and management of mobile devices which runs on top of IP and is thus basically network independent. OTA technology comprises techniques for configuring data, installing features, etc. in mobile terminals, including SIM/USIM applications, over the radio interface (also known as the air interface, hence the name OTA) while the mobile terminal is being used in regular operation, e.g., by a user to make calls. A typical OTA technology is based on the Short Message Service (SMS).
As an example illustrating the problem, assume an owner of an HeNB adds a foreign subscriber to the CSG of the HeNB. The foreign subscriber is thus added to the CSG data in an OMA&P system of the network operator that serves the network to which the HeNB connects. The OMA&P system would then normally inform the network operator's HSS so that the HSS can update the CSG Whitelist in the data record of the concerned subscriber, but the OMA&P system cannot generally communicate with the foreign subscriber's HSS due to a lack of interfaces and/or interface standardization between these nodes. If OMA DM or OTA technology is used for configuring the CSG Whitelist in the UE, the OMA&P system would normally also perform this task, but the OMA&P system is not authorized to configure data in the UE of a foreign subscriber (e.g., it lacks the appropriate security related data and possibly other required data/information). Consequently the UE based CSG Whitelist will not be updated accordingly, so the UE will not become aware that it is included in a new CSG. If the UE should still attempt to access the HeNB, e.g., after a manual override attempt of the UE based CSG Whitelist, a consequence is that the core network node performing the CSG based access control (the core network node serving the UE) will receive a CSG Whitelist from the HSS of the foreign subscriber, which does not include the CSG ID of the concerned CSG and hence the CSG based access control will fail and the UE will be rejected for gaining access to that HeNB.
Accordingly, it would be desirable to have methods and systems which address the afore-described issues associated with CSG roaming.